A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. FIG. 1 graphically represents an authorization code flow 10 for OAuth 2.0 Authorization Framework as reproduced from RFC 6749, Copyright (c) 2012, IETF Trust. RFC 6749, the disclosure of which is hereby incorporated by reference in its entirety, describes the authorization code flow as follows:
The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a Web browser) and capable of receiving incoming requests (via redirection) from the authorization server. The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the user-agent. The flow illustrated in FIG. 1 includes the following steps:
(A) The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
(B) The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client's access request.
(C) Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier (in the request or during client registration). The redirection URI includes an authorization code and any local state provided by the client earlier.
(D) The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step. When making the request, the client authenticates with the authorization server. The client includes the redirection URI used to obtain the authorization code for verification.
(E) The authorization server authenticates the client, validates the authorization code, and ensures that the redirection URI received matches the URI used to redirect the client in step (C). If valid, the authorization server responds back with an access token and, optionally, a refresh token.
OAuth 2.0 may be utilized to enable an application to obtain limited access to an HTTP service on behalf of a resource owner. As noted in the portion of RFC 6749 reproduced above, the client/application, must be capable of interacting with the resource owner's user-agent (Web browser) in order to obtain such access. One non-limiting aspect of the present invention contemplates facilitating similar access without requiring the client/application to interact with the resource owner's user-agent or Web browser.